Design verification is a common process for testing a newly designed integrated circuit, board, or system-level architecture, to, for example, confirm that it complies with the requirements defined by the specification of the architecture for that device. Design verification for a device under test (DUT) may be performed on the actual device, but can usually be a simulation model of the device is tested.
Verification of electronic designs may typically have three forms. At an early stage, before the electronic design is implemented in hardware, simulation can be conducted on a model of the design. Another form can be emulation, in which an electronic hardware may be used to mimic the behavior of another (tested) electronic hardware. At more advanced stages of design development, a system on chip (SoC) may be validated, in a process which is typically referred to as post-silicon validation. Post-silicon validation can be a last stage in the electronic design development, for example, before it is manufactured.
An electronic system (e.g., a smartphone, a tablet, etc.) may typically be made up of a plurality of electronic devices (e.g., memory, camera, central processing unit—CPU, graphical processing unit—GPU, microphone, media player, etc.). At the early stages in the development of an electronic design, a model of each of the electronic devices that form the electronic system can be built (typically in Verilog or other HDL language, and verified by simulating executions of a multitude of tests on the simulation of the DUT. In order to, for example, efficiently cover all (or substantially all) functionalities of the DUT a plurality of tests can be generated. The plurality of tests can be pieces of code, e.g., C-code, assembly, and/or other codes as are known in the art. Each of the plurality of tests can be generated from one of various scenarios which can be constructed by a one or a plurality of users. Each scenario can be made up of a plurality of actions which the user selects to be included in the scenario. The user may also define the order in which the selected actions are to be performed—consecutively or concurrently.
In a typical verification process an electronic design undergoes test regressions which includes designing various validated testing scenarios that are generated in a test code form and executed, in order to find bugs in the design.
Developing a SoC for the automotive market, for example, may demand a different verification approach than the verification approach used in markets such as consumer products. Whereas it may be enough to show that a consumer product does not have any functional bugs, an automotive design may require showing that it does not have any functional safety issues, even if the SoC enters an unexpected state.
To comply with safety standards (e.g., ISO 26262), SoCs that are required to pass safety verification, e.g., SoCs designed for automotive use, may require ensuring that there are no design bugs in the SoCs (e.g., using coverage-driven functional verification), and also that there are no safety risks, such as for example faults caused by an external source (e.g., radiation, physical trauma or other problems, that may cause, for example, an illegal value to appear. Safety risks may be dealt with by employing a functional safety verification strategy that complies with the safety standard/s.
Typically, a functional safety verification strategy may involve employing a fault injection technique, and checking whether the injected fault has caused an unexpected output, and/or whether specific checker or checkers have detected the fault.